Voicemail Archival and Forwarding Functionality for Communications Networks and Devices

ABSTRACT

A voicemail system includes a memory and a processor. The memory can store data relating to one or more users. An incoming communication can be handled by the voicemail system and provided with functionality based upon, for example, preferences of a user. The voicemail system can include functionality to allow a user to archive a voicemail message, to convert a voicemail message to a desired format, and/or to forward a voicemail message or converted voicemail message file to one or more designated destinations. The voicemail system can operate on a communications network, at a communications device, or both. Methods for archiving, converting, and/or forwarding voicemail messages are also disclosed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/964,650, filed Aug. 12, 2013, which is incorporated herein byreference in its entirety; and which is a continuation of U.S. patentapplication Ser. No. 12/161,035, filed Jul. 16, 2008, now U.S. Pat. No.8,509,745, which is incorporated herein by reference in its entirety;and which is a national stage entry of and claims priority to PatentCooperation Treaty Application Number PCT/US2008/067152, filed on Jun.16, 2008, which is incorporated herein by reference in its entirety; andwhich claims priority to U.S. Provisional Patent Application No.60/969,419, filed Aug. 31, 2007, which is incorporated herein byreference in its entirety.

TECHNICAL FIELD

The present disclosure relates generally to voicemail platforms forcommunications devices. More particularly, the present disclosurerelates to systems and methods for providing dynamic voicemail archivaland forwarding functionality for communications networks and devices.

BACKGROUND

Voicemail is a popular telephone service feature, and is often includedin the price paid for telephone service. When a called line withvoicemail functionality does not answer or is busy, a call can behandled by a voicemail system. A voicemail system can store recordingsand/or announcements for a user. When a call is passed to a voicemailsystem, the voicemail system can play one or more recordings and/orannouncements for the calling party or a generic message and can promptthe calling party to leave a message, for example, a spoken message. Thevoicemail system can record the calling party's message and store themessage, for example, as audio data in a storage device. Call dataassociated with the message, for example, the calling party's telephonenumber, the date and time of the call, and the like, can also be storedby the voicemail system and associated with the stored message. Somevoicemail systems also allow calling parties to leave alphanumericmessages for a called party. In any event, the voicemail system canstore the message or data and associated call data.

Among the close to 100 million cellular telephone service users in theUnited States, a growing trend includes replacing terrestrial telephoneservices with cellular telephone services. In the event that a userdetermines to replace other telephone service with a cellular telephoneline, a cellular telephone service may be the user's only telephonenumber. As such, voicemail service associated with a cellular telephoneline can be relied upon by a user to report all missed telephone calls,whether those calls relate to personal or business matters.

The increased reliance upon cellular telephone service has beenaccompanied by a corresponding increased demand and increased relianceupon other cellular telephone features and functionality, for example,text messaging, email, Internet browsing, data transfer, and otherfeatures. As reliance upon and demand for cellular telephone servicesand voicemail increases, demand for enhanced voicemail services willlikely continue to experience a corresponding increase.

SUMMARY

A system for providing voicemail archival functionality for acommunications network can include a memory configured to storeinstructions and messages, a processor configured to execute theinstructions stored in the memory, and a network interface. Theinstructions stored in the memory can include a voicemail applicationconfigured to obtain and store one or more messages from a calling partyand a voicemail archival application configured to archive one or morestored messages. The voicemail application can further includeinstructions for converting one or more archived messages from a firstfile format to a second file format, for example, an audio file can beconverted from adaptive multi-rate (AMR) to waveform audio (WAV), andthe like. The instructions stored in the memory can include instructionsfor forwarding one or more archived messages to one or more recipients.The instructions stored in the memory can also include a billingapplication The instructions for archiving one or more stored messagescan include instructions for sending a save command to the voicemailsystem at designated intervals and reiterating the sending of the savecommand indefinitely or for some designated period of time. For example,a user can determine that a message should be kept for one month. Insuch a case, the device or voicemail system can send a save command tothe voicemail application at any interval necessary to ensure survivalof the message for at least one month. In other embodiments, theinstructions for archiving the one or more stored messages includesinstructions for adding identifying information, for example, a tag orheader data, to a stored message to designate the message as an archivedmessage. In some embodiments, the instructions for archiving the one ormore stored messages includes instructions for moving a stored messagefrom a first memory location corresponding to a storage location to asecond memory location corresponding to an archival location. The firstand second memory locations can be part of the save storage device, orparts of separate devices.

A method for archiving one or more messages using a voicemail forwardingapplication of a voicemail system can include receiving, at thevoicemail system, instructions to archive one or more messages andexecuting, at the voicemail system, instructions for archiving the oneor more messages. The one or more archived messages can be stored at amemory location of the voicemail system corresponding to an archivelocation. The storage of an archived message can persist independent ofmessage operations performed at other voicemail system locations, anduntil the archived message is moved from the archive location. Forexample, deletion of a message at a voicemail system can be ignored byother elements. As such, an archived message can be stored independentof changes made to other voicemail storage elements or messages therein.The instructions for archiving the one or more messages can includeinstructions for tagging the one or more messages as archived messages,for example, with a tag or header data. The archive location can be amemory location of the voicemail system or the mobile device. Theinstructions for archiving the one or more messages can includeinstructions for moving the one or more messages to the archive locationof the voicemail system. In some embodiments, the archive location isseparate from a storage location in which messages are stored prior toarchival. In other embodiments, the stored and archived messages arestored in the same place. The instructions for archiving the one or moremessages can include instructions for sending a save command to thevoicemail system to save the one or more messages in the archivelocation of the voicemail system. The sending of the save command can berepeated at any designated interval to prevent deletion of the messagefrom the voicemail system memory.

A mobile device including voicemail archival functionality can includememory configured to store instructions and messages, a processor forexecuting the instructions stored in the memory, and a network interfacefor transferring data to and from at least one cellular network. Theinstructions stored in the memory can include a voicemail applicationfor storing one or more messages in the memory and a voicemail archivalapplication for archiving one or more messages in the memory. The mobiledevice can also store messages at a network node, for example, a memorylocation at a voicemail system. The voicemail archival application canalso include instructions for converting the one or more messages from afirst file format to a second file format. The one or more messages canbe stored at a memory location at the cellular network and a firstmemory location at the device and archived messages can be stored at asecond memory location at the device. The one or more messages can bedeleted from the memory location at the cellular network when the one ormore messages are deleted from the first memory location at the device.The one or more archived messages can be stored independent of deviceand voicemail system actions. As such, the archived messages need not bedeleted from the second memory location at the device until the archivedmessages are selected and deleted.

These and additional features of the present disclosure will becomeapparent with reference to the attached drawings, wherein:

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 schematically illustrates an exemplary communications networkwith which embodiments of the present disclosure can be implemented.

FIG. 2 schematically illustrates a voicemail system, according to anexemplary embodiment of the present disclosure.

FIG. 3 schematically illustrates a block diagram of an exemplary mobiledevice for use with exemplary embodiments of the present disclosure.

FIG. 4 is a call flow diagram illustrating an exemplary method fordownloading a voicemail deposited at a voicemail system to a device,according to an exemplary embodiment of the present disclosure.

FIG. 5 is a call flow diagram illustrating an exemplary method fordeleting a voicemail message from a device and from a voicemail system,according to an exemplary embodiment of the present disclosure.

FIG. 6 is a call flow diagram illustrating an exemplary method fordeleting a voicemail message from a voicemail system and from a device,according to an exemplary embodiment of the present disclosure.

FIG. 7 is a call flow diagram illustrating an exemplary method forarchiving a voicemail message at a device, according to an exemplaryembodiment of the present disclosure.

FIG. 8 is a call flow diagram illustrating an exemplary method forarchiving a voicemail message at a voicemail system, according to anexemplary embodiment of the present disclosure.

FIG. 9 is a call flow diagram illustrating an exemplary method forarchiving a voicemail message at a voicemail system, initiated at anetwork element, or at a device, according to an exemplary embodiment ofthe present disclosure.

FIG. 10 illustrates an exemplary graphical user interface (GUI) for avoicemail management client including an option for a user to archivevoicemail messages, according to an exemplary embodiment of the presentdisclosure.

FIG. 11 illustrates another exemplary GUI for a voicemail managementclient allowing a user to view archived messages and giving the user anoption to forward voicemail messages, according to an exemplaryembodiment of the present disclosure.

FIG. 12 illustrates another exemplary GUI for a voicemail managementclient allowing a user to view archived messages and giving the user anoption to forward voicemail messages, according to an exemplaryembodiment of the present disclosure.

FIG. 13 illustrates an exemplary GUI for providing an option for a userto designate a conversion format and a forwarding method for a forwardedvoicemail message, according to an exemplary embodiment of the presentdisclosure.

FIG. 14 illustrates an exemplary GUI interface for forwarding avoicemail message, according to an exemplary embodiment of the presentdisclosure.

FIG. 15 schematically illustrates an exemplary method for forwardingvoicemail messages, according to an exemplary embodiment of the presentdisclosure.

DESCRIPTION

As required, detailed embodiments of the present disclosure aredisclosed herein. It must be understood that the disclosed embodimentsare merely exemplary examples of the disclosure that may be embodied invarious and alternative forms, and combinations thereof. As used herein,the word “exemplary” is used expansively to refer to embodiments thatserve as an illustration, specimen, model or pattern. The figures arenot necessarily to scale and some features may be exaggerated orminimized to show details of particular components. In other instances,well-known components, systems, materials or methods have not beendescribed in detail in order to avoid obscuring the present disclosure.Therefore, specific structural and functional details disclosed hereinare not to be interpreted as limiting, but merely as a basis for theclaims and as a representative basis for teaching one skilled in the artto variously employ the present disclosure.

Referring now to the drawings in which like numerals represent likeelements throughout the several views, FIG. 1 schematically illustratesan exemplary communications network 10. The illustrated exemplarynetwork 10 includes a cellular network 12, the Internet 14, and a PSTN16. The cellular network 12 can include various components such as, butnot limited to, base transceiver stations (BTSs), base stationcontrollers (BSCs), mobile switching centers (MSCs), short messageservice centers (SMSCs), multimedia messaging service centers (MMSCs),home location registers (HLRs), charging platforms, traditional or plainold voicemail platforms, visual voicemail platforms, GPRS core networkcomponents, and the like. A mobile device 18, such as, for example, acellular telephone, a user equipment, a mobile terminal, a PDA, ahandheld computer, a laptop computer, or a combination thereof, can beoperatively linked and in communication with the cellular network 12. Itshould be understood that any device and/or network can be used withembodiments of the present disclosure.

The cellular network 12 can be configured as a 2G GSM (Global System forMobile communications) network and provide data communications via GPRS(General Packet Radio Service), and EDGE (Enhanced Data rates for GSMEvolution). Additionally, the cellular network 12 can be configured as a3G UMTS (Universal Mobile Telecommunications System) network and canprovide data communications via the HSPA (High-Speed Packet Access)protocol family, for example, HSDPA (High-Speed Downlink Packet Access),EUL (Enhanced Uplink) or otherwise termed HSUPA (High-Speed UplinkPacket Access), and HSPA+ (Evolved HSPA). The cellular network 12 isalso compatible with future mobile communications standards including,but not limited to, pre-4G and 4G, for example.

The illustrated cellular network 12 is shown in communication with theInternet 14 and a PSTN 16, though it will be appreciated that this isnot necessarily the case. The cellular network 12 can include a widearray of nodes, devices, subsystems, networks, subnetworks, software,hardware, applications, and the like. For example, a cellular network 12can include one or more messaging systems or nodes, for example, shortmessage service centers (SMSCs), multimedia message service centers(MMSCs), voicemail systems, content delivery servers, and the like. Acellular network 12 can also include various radios and nodes forpassing voice, data, and combinations thereof to and from radiotransceivers, networks, and the Internet 14.

One or more Internet-capable devices 20, for example, a PC, a laptop, aportable device, an Internet-capable cellular telephone, a smart phone,or any other suitable device, can communicate with one or more cellularnetworks 12, or even a device 18 connected thereto, through the Internet14. It will also be appreciated that the internet device 20 cancommunicate with the Internet 14, through the PSTN 16, the cellularnetwork 12, or a combination thereof. As illustrated, a communicationsdevice 22, for example, a telephone, facsimile machine, modem, computer,or the like, can be in communication with the PSTN 16, and therethroughto the Internet 14 and/or the cellular network 12. It will beappreciated that the communications device 22 can be an Internet-capabledevice, and can be substantially similar to the Internet-capable device20.

The illustrated communications network 10 includes a voicemail system 24(VMS), a content delivery server 26 (CDS) for delivering messages andmessage content to mobile devices 18, and a message waiting icon server28 (MWIS). The MWIS 28 can be or can include one or more short messageservice centers (SMSCs). The VMS 24 can be hardware, software, and/or acombination thereof, and includes traditional POVM voicemail systems aswell as visual voicemail systems. While the VMS 24, the CDS 26, and theMWIS 28, are illustrated as being connected to the cellular network 12,it will be appreciated that the VMS 24, the CDS 26, and the MWIS 28, caneach be hardware and/or software residing on one or more of the cellularnetwork 12, the PSTN 16, the mobile device 18, the Internet 14, and thatthe VMS 24, the CDS 26, and the MWIS 28, can be accessible by and/orthrough multiple devices and networks, including private networks, whichare not illustrated in FIG. 1. It should be appreciated thatsubstantially all of the functionality described with reference to thecommunications network 10 can be performed by the cellular network 12.

FIG. 2, schematically illustrates a block diagram of a VMS 24, accordingto an exemplary embodiment of the present disclosure. The illustratedVMS 24 includes a communications network interface 30 that isoperatively linked and in communication with a processor 32 via adata/memory bus 34. The communications network interface 30 can allowthe VMS 24 to communicate with one or more components of thecommunications network 10, or any device connected to or residing on thecommunications network 10. It will be appreciated that if the VMS 24resides on mobile device, for example, the device 18, that thecommunications network interface 30 can be a communications component ofthe device 18, for example, a short range radio device, a transceiver,receiver, transmitter, antennae, a connection port, or combinationsthereof. The processor 32 is operatively linked and in communicationwith a memory 36 via a data/memory bus 34.

The word “memory,” as used herein to describe the memory 36,collectively refers to all memory types associated with the VMS 24 suchas, but not limited to, processor registers, processor cache, randomaccess memory (RAM), other volatile memory forms, and non-volatile,semi-permanent or permanent memory types; for example, tape-based media,optical media, flash media, hard disks, combinations thereof, and thelike. While the memory 36 is illustrated as residing proximate theprocessor 32, it should be understood that the memory 36 can be aremotely accessed storage system, for example, a server on the Internet14, a remote hard disk drive, a removable storage medium, combinationsthereof, and the like. Moreover, the memory 36 is intended to encompassnetwork memory and/or other storage devices in wired or wirelesscommunication with the VMS 24, which may utilize the communicationsnetwork interface 30 to facilitate such communication. Thus, any of thedata, applications, and/or software described below can be stored withinthe memory 36 and/or accessed via network connections to other dataprocessing systems (not shown) that may include a local area network(LAN), a metropolitan area network (MAN), or a wide area network (WAN),for example. Accordingly, the present disclosure may operate on the VMS24, wherein the VMS 24 is configured as a server to one or more clientdata processing systems as dictated by a client/server model.

The illustrated memory 36 can include one or more voicemail applications38 (VMAs), one or more voicemail archival and/or forwarding applications40 (VMAFs), one or more CODECs 42, and one or more billing modules 44.Additionally, the memory 36 can include other data, software,instructions, applications, and the like, for example, an operatingsystem (not illustrated), hardware data, firmware, and the like.Although the VMA 38, the VMAF 40, the CODECs 42, and the billing modules44 are shown as separate entities, it should be appreciated thatsubstantially all of the functionality of the VMS 24 modules can beperformed by a single application, program, utility, software package,or the like. The memory 36 can also include user data 46.

The VMA 38 can include instructions, programs, applications, software,and the like, for handling communications passed to the VMS 24. The VMA38 can examine the communication passed to the VMS 24 to determine, forexample, the called party, i.e., the user and the mailbox associatedwith the user. The VMS 24 can then retrieve the user's greetings or adefault greeting for the user and record a message from the callingparty for the called party. A message, as will be explained below inmore detail, can include an audio recording, a text message, a videorecording, an alphanumeric page, headers, and the like. The VMA 38 canalso support message retrieval by a user or a user's device, as well asproviding a telephone user interface (TUI) for calling parties andusers. It will be appreciated that the VMA 38 can, but does notnecessarily, operate in a manner substantially similar to traditionalPOVM voicemail systems and/or visual voicemail systems.

The VMAF 40 can include instructions, programs, applications, softwareand the like, for archiving messages. The VMAF 40 can archive messagesat a network element or at a device 18, as will be explained in moredetail below. The VMAF 40 can also include instructions, programs,applications, software, and the like, for forwarding messages, orportions thereof. The messages can be archived and/or forwarded in anydesired format. As such, the VMAF 40 can include instructions, programs,applications, software, and the like, for converting messages, orportions thereof, to alternative formats, as will be explained in moredetail below.

The VMAF 40 can convert audio or video files to alternative audio orvideo formats. Additionally, the VMAF 40 can convert an audio portion ofa message to text. The VMAF 40 can, if desired, use an algorithm, forexample, a CODEC, to encode or decode audio files and/or convert filesto alternative formats. Messages can be archived as compressed files toreduce the use of network resources, if desired. Alternatively, themessages can be stored without any conversion and/or compression. TheVMAF 40 can also format the delivery method of the messages, orportion(s) thereof. For example, the VMAF 40 can format an email messageand attach a message, or a portion thereof, to the email message. Otherarchival functions, conversion formats, and delivery methods will bedescribed below in more detail.

The CODECs 42 can include algorithms, programs, and/or software that isused by a hardware device or software to compresses or decompressesdata, for example, video and audio data. It will be appreciated that theterm “CODEC,” as used herein and in the claims, refers to any algorithm,program, application, routine, subroutine, and the like, used tocompress and/or decompress data. In the illustrated VMS 24, the CODECs42 can be used by the VMAF 40 to convert voicemail message data. TheCODECs 42 can include algorithms that direct computer programs orhardware devices, for example, how to represent a video or audio file ina manner that uses a minimum amount of data while retaining the originalvideo or audio file quality. The use of the CODECs 42 can reduce theamount of storage space needed to store a video or audio file.Similarly, the CODECs 42 can be used to minimize the bandwidth requiredto transmit a video or audio file to, from, or through thecommunications network 10, or a device 18, 20, 22 connected thereto.

The billing module 44 can be used to track, collect, and/or reportactivities of the VMS 24 for billing purposes. For example, the billingmodule 44 can track how many messages are archived by the VMS 24 and howlong each message has been archived. Additionally, the VMS 24 can trackhow much data is converted and or sent and received by the VMS 24 andreport this information to a billing system of the communicationsnetwork 10, for example. Billing can be pre-paid or post-paid. The VMS24 archival, conversion, and/or forwarding functionalities can becharged on any desired basis, including, but not limited to, a per-usebasis, a per-message basis, a duration basis, a file size basis, aper-byte basis, a per-kilobyte basis, combinations thereof, and thelike. Additionally, or in the alternative, the archival, conversion, andforwarding functionalities can be billed as a flat fee, for example, aspart of service package, or the like. In one embodiment, the archival,conversion, and forwarding functions, as well as other functionality,are included as features in an “Advanced Voicemail” package.

The user data 46 can include various types of data. For purposes ofillustration, and not limitation, the user data 46 is illustrated inFIG. 2 and described herein as including a number of categories of datathat can be associated with one or more users of the VMS 24. Exemplarycategories of user data 46 can include, for example, greetings andannouncements (“greetings”) 48, user preferences 50, messages 52,account/device data 54, archived messages in the archive 56, and otherdata (not illustrated). The user data 46 can be configured, stored,synced, updated, and deleted by any number of users, network operators,or other authorized parties. It will be appreciated that the greetings48, user preferences 50, messages 52, account/device data 54, archivedmessages in the archive 56, and other data, can be updated by a user ofthe VMS 24, or by any other authorized party. The messages 52 can beupdated and stored by the VMS 24, for example, when a calling partyleaves a message for the user or when a message is sent to the user.

The greetings 48 can include greetings, announcements, forwardinggreetings, schedules, and the like, and can be associated with a user.The greetings 48 can be configured by the user, by a network node, bythe VMS 24, or by any other authorized party or device. For example, auser can record a greeting, schedule, a greeting introducing a forwardedmessage, an announcement, or the like, and store the greeting 48 on theVMS 24. As such, the greetings 48 can be audio data that is stored inthe VMS memory 36 as, for example, an audio file. Additionally, thegreetings 48 can be default messages that are created by the network ora network node and tailored for a user. The greetings 48 can be storedin any desired format. If the greetings 48 are stored as audio data,exemplary formats include, but are not limited to, waveform audio (WAV),audio interchange file format (AIFF), RAW, encoded in GSM CODEC,advanced audio coding (AAC), MPEG-1 audio layer 3 (MP3), MPEG-4 Part 14(MP4 or M4A), Windows® media audio (WMA), RealAudio (RA), free losslessaudio codec (FLAC), Apple® lossless encoder (ALE), i.e., Apple® losslessaudio codec (ALAC), and other open and proprietary audio formats. Itwill be appreciated that the greetings 48, messages 52, and archivedmessages in the archive 56 can be converted as desired between one ormore file formats.

The user preferences 50 can include data relating to a user'spreferences for the VMS 24. The user preferences 50 can include, forexample, an indication as to which functions the user wishes to makeavailable to calling parties, archival locations, the class of service(CoS) for a user, conversion formats supported by the user's device,forwarding destination information, e.g., telephone numbers, emailaddresses, facsimile numbers, and the like, message time limits, voiceto text settings, the number of rings allowed prior to passing a call tothe VMS 24, message waiting indicator preferences, download settings,data routing preferences, and the like. It will be understood that userscan customize many other functions and options of the VMS 24, including,for example, options for bypassing the VMS 24 and sending incoming callsfor a user to another system, phone number, and/or user, forwardingnumbers, voice or data delivery options, including formats, size,delivery times, email addresses, and the like, as well as otherpreferences.

The messages 52 can include, for example, audio files created byrecordings made by the VMS 24, text created by a calling party or by theVMS 24, video messages, headers associated with audio, video, or text,and the like. For example, if a calling party leaves a spoken messagefor a called party, an audio file associated with a message 52 can becreated by recording the spoken message. The audio files, if any, can bestored in any desired format, including, but not limited to, WAV, AIFF,RAW, encoded in GSM CODEC, AAC, MP3, MP4, M4A, WMA, RA, FLAC, ALE, ALAC,and other open and proprietary audio formats. Text data of the message52 can include text created by the VMS 24, for example, using a speechto text converter. The text data can also include text created by orentered by the calling party, for example, an alphanumeric message, acallback number, a text message, and the like. The headers of themessage 52 can include call data such as the MSISDN, the length of themessage, the size of the text file, if applicable, the time and date ofthe call, priority information, and the like. In addition to the fileformats discussed above, the video files, audio files, headers, and textcan be stored in any network-recognizable format. The various dataassociated with a message 52 can be stored by the VMS 24 in any manner.If desired, the various data can be correlated to associate an audiofile, a text file, and headers with each other as part of a message 52.

Time limits can be set to designate the “life” of one or more messages52. In some embodiments, the messages 52 have a life of 14 days, afterwhich the messages 52 can be automatically deleted from the VMS 24. Inother embodiments, the life is set at 30 days. In still otherembodiments, the data remains on the VMS 24 until a user deletes themessage from the VMS 24. In some embodiments, the set time limit for thelife of a message 52 does not begin to run until a user reviews themessage 52. In still other embodiments, the time limit is set to anydesired duration and is measured in any desired units, including, butnot limited to, seconds, minutes, hours, days, weeks, months, and thelike.

Account/device data 54 can include data relating to the user's accountand/or device, including, but not limited to, the user's subscriptionplan and the user's device capabilities. For example, the VMS 24 can bein communication with one or more billing platforms, subscriberdatabases, other network nodes, and the like, to receive theaccount/device data 54 relating to a user's subscription plan, usage,and billing information. Additionally, the account/device data 54 caninform the VMS 24 of the features the user's device supports byindicating the IMEI, serial number, carrier, software version(s),firmware, carrier-specific applications, combinations thereof, or thelike. The account/device data 54 can pass-through the VMS 24, or can bestored, at least temporarily by the VMS 24. The VMS 24 can use theaccount/device data 54 to determine file formats and functionality thatshould be provided to a calling party or a user based upon billing,device, network, or other considerations. Additionally, billingconsiderations can be used to tailor options presented to a callingparty or a user. For example, a user can instruct the VMS 24 to enableor disable various functions of the VMS 24 such as the ability to sendtext messages, the ability to archive messages, the ability to forwardvoicemail messages, and the like. Additionally, or in the alternative, anotification can be sent from a billing platform to the VMS 24 directlyand the VMS 24 can disable functionality automatically. A user can begiven the ability to override deactivation of any desired features orfunctionality.

Archived messages in the archive 56 can include data relating tomessages that have been archived by the VMS 24, a user, or any otherauthorized party or system. As will be explained below in more detail,in some embodiments, messages are archived by moving messages, or copiesthereof, as archived messages in an archive 56 portion of the VMS memory36. In other embodiments, messages are archived by “tagging” messageswith data that indicates to the VMS 24 that the message is to bearchived. A “tag” can include a header or other piece of data as part ofthe message, or corresponding to the message, that indicates thearchived status of the message. This tag can be interpreted by the VMS24 and employed to prevent, either permanently or temporarily, deletionof an archived message. In still other embodiments, messages arearchived by downloading or forwarding an archived message to a device 18or other designated recipient. These and other embodiments are discussedbelow in more detail.

FIG. 3 illustrates a schematic block diagram of an exemplary mobilecommunications device 18 for use in accordance with an exemplaryembodiment of the present disclosure. Although no connections are shownbetween the components illustrated in FIG. 3, the components caninteract with each other to carry out device functions.

As illustrated, the mobile communications device 18 can be a multimodehandset. It should be understood that FIG. 3 and the followingdescription are intended to provide a brief, general description of asuitable environment in which the various aspects of an embodiment ofthe present disclosure can be implemented. While the descriptionincludes a general context of computer-executable instructions, thepresent disclosure can also be implemented in combination with otherprogram modules and/or as a combination of hardware and software. Theterm “application,” or variants thereof, is used expansively herein toinclude routines, program modules, programs, components, datastructures, and the like. Applications can be implemented on varioussystem configurations, including single-processor or multiprocessorsystems, minicomputers, mainframe computers, personal computers,hand-held computing devices, microprocessor-based, programmable consumerelectronics, combinations thereof, and the like.

The device 18 can include a variety of computer readable media,including volatile media, non-volatile media, removable media, andnon-removable media. Computer-readable media can include device storagemedia and communication media. Storage media can include volatile and/ornon-volatile, removable and/or non-removable media such as, for example,RAM, ROM, EEPROM, flash memory or other memory technology, CD ROM, DVD,or other optical disk storage, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium that can be used tostore the desired information and that can be accessed by the device 18.

The device 18 can include a display 58 for displaying multimedia suchas, for example, text, images, video, telephony functions such as CallerID data, setup functions, menus, music, metadata, messages, wallpaper,graphics, internet content, device status, preferences settings, mapdata, location data, and the like. The device 18 can include a processor60 for controlling, and/or processing data. A memory 62 can interfacewith the processor 60 for the storage of data and/or applications 64. Anapplication 64 can include, for example, video player software,voicemail software, conversion software, archival software, forwardingsoftware, audio playback software, music player software, emailsoftware, messaging software, combinations thereof, and the like. Theapplication 64 can also include a user interface (“UI”) application 66.The UI application 66 can interface with a client 68 (e.g., an operatingsystem) to facilitate user interaction with device functionality anddata, for example, answering/initiating calls, entering/deleting data,configuring settings, address book manipulation, multimode interaction,and the like. The applications 64 can include other applications 70 suchas, for example, firmware, visual voicemail software, add-ons, plug-ins,voice recognition, call voice processing, voice recording, messaging,e-mail processing, video processing, image processing, voicemail filearchival, converting, and forwarding, music play, combinations thereof,and the like, as well as subsystems and/or components. The applications64 can be stored in the memory 62 and/or in a firmware 72, and can beexecuted by the processor 60. The firmware 72 can also store code forexecution during initialization of the device 18.

A communications component 74 can interface with the processor 60 tofacilitate wired/wireless communications with external systemsincluding, for example, cellular networks, VoIP networks, LAN, WAN, MAN,PAN, that can be implemented using Wi-Fi, Wi-Max, combinations and/orimprovements thereof, and the like. The communications component 74 canalso include a multimode communications subsystem for providing cellularcommunications via different cellular technologies. For example, a firstcellular transceiver 76 can operate in one mode, for example, GSM, andan Nth transceiver 78 can operate in a different mode, for example UMTS.While only two transceivers 76, 78 are illustrated, it should beappreciated that a plurality of transceivers can be included. Thecommunications component 74 can also include a transceiver 80 forunlicensed communications using technology such as, for example, WI-FI,WI-MAX, BLUETOOTH, infrared, IRDA, NFC, RF, and the like. Thecommunications component 74 can also facilitate communications receptionfrom terrestrial radio networks, digital satellite radio networks,Internet-based radio services networks, combinations thereof, and thelike. The communications component 74 can process data from a networksuch as, for example, the Internet, a corporate intranet, a homebroadband network, and the like, via an ISP, DSL provider, or broadbandprovider.

An input/output (I/O) interface 82 can be provided for input/output ofdata and/or signals. The I/O interface 82 can be a hardwire connection,such as, for example, a USB, mini-USB, audio jack, PS2, IEEE 1394,serial, parallel, Ethernet (RJ48), RJ11, and the like, and can acceptother I/O devices such as, for example, a keyboard, keypad, mouse,interface tether, stylus pen, printer, thumb drive, touch screen, touchpad, trackball, joy stick, microphones, remote control devices, monitor,display, LCD, combinations thereof, and the like. It will be appreciatedthat the I/O interface 82 can be used for communications between thedevice and a network or local device, instead of, or in addition to, thecommunications component 78.

Audio capabilities can be provided by an audio I/O component 84 that caninclude a speaker for the output of audio signals and a microphone tocollect audio signals. The device 18 can include a slot interface 86 foraccommodating a subscriber identity system 88 such as, for example, aSIM or universal SIM (USIM). The subscriber identity system 88 insteadcan be manufactured into the device 18, thereby obviating the need for aslot interface 86. The device 18 can include an image capture andprocessing system 90. Photos and/or videos can be obtained via anassociated image capture subsystem of the image system 90, for example,a camera. The device 18 can also include a video component 92 forprocessing, recording, and/or transmitting video content.

A location component 94, can be included to send and/or receive signalssuch as, for example, GPS data, triangulation data, combinationsthereof, and the like. The device 18 can use the received data toidentify its location or can transmit data used by other devices todetermine the device 18 location. The device 18 can include a powersource 96 such as batteries and/or other power subsystem (AC or DC). Thepower source 96 can interface with an external power system or chargingequipment via a power I/O component 98.

FIG. 4 schematically illustrates an exemplary method 100 for voicemailmessage deposit and subsequent retrieval of message content for localstorage on a mobile device. It should be understood that the stepsdescribed are not necessarily presented in any particular order and thatperformance of some or all of the steps in an alternative order(s) ispossible and is contemplated. The steps have been presented in thedemonstrated order for ease of description and illustration. Steps canbe added, omitted and/or performed simultaneously without departing fromthe scope of the appended claims. Some or all steps of this process,and/or substantially equivalent steps, can be performed by execution ofcomputer-readable instructions included on a computer readable medium.

In an attempt to simplify the description of the method 100, variousnetwork elements and nodes have been omitted from the illustrated callflow diagram. Similarly, messages and data are described in genericterms, though it will be appreciated that multiple message and dataformats, as well as multiple message and data nodes, relays, andmessaging platforms can be involved in any or all of the communicationsdescribed herein.

In an additional attempt to simplify the description and to avoidcomplicating the disclosure, the following description will describe, ingeneral terms, performance of various methods embodying some concepts ofvarious embodiments of the disclosure. In reading the description of theseveral methods herein, it should be understood that a user can interactwith a VMS 24 using a telephone user interface (TUI), a GUI, or anotherUI. Alternatively, a user can interact with the device 18, and thedevice 18 can handle all communication needed to instruct the VMS 24 howto carry out the user's desired actions. Therefore, DMTF-driven TUIs,icon-based GUIs, touch-sensitive screen GUIs, voice-driven TUIs, and thelike are included in the following descriptions of the exemplary methodsdisclosed herein and are included in the scope of the appended claims.

The illustrated message method 100 begins with a message being depositedat the VMS 24, as illustrated at step 102. In the illustratedembodiment, the VMS 24 notifies the CDS 26, for example, by generating aSMPP notification message (notification SM) that is sent to the CDS 26,as shown at step 104. A notification SM message can include, but is notlimited to, the hostname and port number for the subscriber's CDS 26, atoken identifying the subscriber's VMS 24, the subscriber's voicemailbox ID embedded with a token to uniquely identify the subscriber for theVMS 24, and the current VMS password. In some alternative embodiments,the notification_SM includes an IP address and port number for thesubscriber's CDS 26 and a mailbox_ID. The password and token can beadded to help increase security and to help preserve data integrity. Ifa password is used, the password can be encrypted or unencrypted, and/orthe password can be obscured to hide the actual default password digits.

The CDS 26 can forward the notification_SM message, at step 106, to theSMSC (which can be part of the MWIS 28) that, in turn, can forward themessage, at step 108, to the device 18. The device 18 receives thenotification_SM message and generates an HTTP message get_headers thatis sent to the CDS 26, at step 110. The get_headers message can includeparameters such as the date, time, and calling line identity (CLI). Theget_headers message can additionally include authentication informationfor IMAP sessions between the CDS 26 and VMS 24. At step 112, the CDS 26initiates an IMAP session with the VMS 24. Accordingly, a TCP connectionis established and the get_headers message is used to authenticate thesession, after which the subscriber's voicemail box is accessed on theVMS 24 to retrieve the header information for the voicemail messages.The VMS 24 sends the headers to the CDS 26, at step 114. The CDS 26forwards the headers to the device 18, at step 116. The device 18 usesthe headers to determine the status of each message stored on the device18 and identity any newly deposited messages. After the device 18determines which message(s) needs to be retrieved, the device 18generates and sends a message request, for example, an HTTP get_messagerequest with the header information for the requested message(s), atstep 118. At step 120, this message is received and the CDS 26 generatesand sends an IMAP message_request, including the requested voicemailmessage header information, to the VMS 24. The VMS 24 processes therequest and returns the requested message content in an IMAPmessage_response, at step 122. The CDS 26 then delivers the designatedmessage content to the device 18, at step 124. Upon receipt of themessage content, the device 18 stores the content under the appropriateheader in a memory and permits the subscriber to access the content viaa user interface, for example, a graphical user interface (GUI). Themessage content can be formatted using any audio CODEC, such as, but notlimited to, adaptive multi-rate (AMR), AMR wideband (AMR-WB), or anyother standardized or independent audio CODEC, including the CODECs 42and audio formats described above with reference to FIG. 2.

In certain embodiments, an “if-modified-since” HTTP Message can be usedto occasionally poll the VMS 24 for the Inbox voicemail message list andupdate any voicemail message “if-modified-since” the last update, forexample, if a message was deleted, archived, or added at the device 18or the VMS 24. This reduces the amount of data traversing the networkthereby reducing network congestion. However, in some embodiments theheader information is relatively small and as such no noticeableimprovement may be available for sending only the modified voicemailmessage header.

In certain embodiments, more than one connection can be established tothe VMS 24 or in some cases to multiple or redundant VMSs. This allowsfor simultaneous requests in order to serve a subscriber's request toview or listen to a message faster. In some other embodiments, messagesare transferred to a device 18 upon receipt by the VMS 24. Loadbalancing techniques can also be implemented. In certain embodiments,message downloads that are interrupted, for example, via cancellation orconnection failure, can be resumed starting at the last received byte.These embodiments assume the message is stored in full, at leasttemporarily, on the CDS 26. However, in some embodiments, the CDS 26deletes the message after the message content is sent to the device 18.A subsequent request for one or more previously sent messages isfacilitated by re-retrieving the message, re-transcoding the message,and sending the message to the device 18. In certain embodiments,requests to the CDS 26 can be pipelined in accordance with HTTP 1.1specifications. This can reduce network latency for multiple requests.

FIG. 5 schematically illustrates an exemplary method 200 for deleting amessage from a device 18 and the VMS 24, wherein the deletion of themessage is initiated at the device 18. It should be understood that thesteps described are not necessarily presented in any particular orderand that performance of some or all of the steps in an alternativeorder(s) is possible and is contemplated. The steps have been presentedin the demonstrated order for ease of description and illustration.Steps can be added, omitted and/or performed simultaneously withoutdeparting from the scope of the appended claims. Some or all steps ofthis process, and/or substantially equivalent steps, can be performed byexecution of computer-readable instructions included on a computerreadable medium.

In an attempt to simplify the description of the method 200, variousnetwork elements and nodes have been omitted from the illustrated callflow diagram. Similarly, messages and data are described in genericterms, though it will be appreciated that multiple message and dataformats, as well as multiple message and data nodes, relays, andmessaging platforms can be involved in any or all of the communicationsdescribed herein.

As illustrated in FIG. 5, the method 200 can begin at step 202, whereata delete message command is received at the device 18. The deletemessage command can be selected by a user, for example, through agraphical user interface (GUI) at the device 18. In the illustratedmethod, the device 18 stores messages, or copies thereof, in a localmemory, for example, a memory 62. In the illustrated method 200, thedevice 18 deletes the selected message from the device memory 62, asillustrated by step 204. As illustrated by step 206, the device 18 canalso send a delete message request to the VMS 24. While it has beenstated above, it is again stressed that the order of the illustratedsteps is exemplary only, and that the steps can be performed in anyorder, or not at all. The delete message request can include informationrelating to the designated message, for example, a reference to amessage header or a portion thereof, and an instruction to delete themessage from the VMS memory 36. The VMS 24 can delete the designatedmessage from the VMS 24, as illustrated at step 208.

FIG. 6 schematically illustrates an exemplary method 300 for deleting amessage from the VMS 24 and a device 18, wherein the deletion of themessage is initiated at the VMS 24. It should be understood that thesteps described are not necessarily presented in any particular orderand that performance of some or all of the steps in an alternativeorder(s) is possible and is contemplated. The steps have been presentedin the demonstrated order for ease of description and illustration.Steps can be added, omitted and/or performed simultaneously withoutdeparting from the scope of the appended claims. Some or all steps ofthis process, and/or substantially equivalent steps, can be performed byexecution of computer-readable instructions included on a computerreadable medium.

In an attempt to simplify the description of the method 300, variousnetwork elements and nodes have been omitted from the illustrated callflow diagram. Similarly, messages and data are described in genericterms, though it will be appreciated that multiple message and dataformats, as well as multiple message and data nodes, relays, andmessaging platforms can be involved in any or all of the communicationsdescribed herein.

As illustrated in FIG. 6, the method 300 can begin at step 302, whereata delete message command is received at the VMS 24. The delete messagecommand can be selected by a user, for example, through a telephone userinterface (TUI) at the VMS 24. The VMS 24 deletes the designated messagefrom the VMS memory 36, as illustrated by step 304. In the illustratedmethod, the device 18 also stores copies of the messages, in a memory62. As such, the VMS 24 can send a delete_message request to the device18, as illustrated at step 306. The delete_message request can includeinformation relating to the designated message, for example, a referenceto a message header or a portion thereof, and an instruction to deletethe message from the device 18. The device 18 can delete the designatedmessage from the device 18, as illustrated at step 308. While FIG. 6depicts a system in which the device 18 and the VMS 24 both storemessages, or at least copies thereof, it will be appreciated that amessage can be forwarded to the device 18 upon receipt by the VMS 24.After forwarding the messages to the device 18, the VMS 24 can deletethe message from the VMS memory 36. In some embodiments, messages arenot stored at the VMS 24 unless a user decides to archive a message, atwhich time a copy of the archived message can be transferred to the VMS24 and stored in the archive 56. These and other functions will bedescribed below in more detail.

FIG. 7 schematically illustrates an exemplary method 400 for archiving amessage at a device 18, wherein the archival of the message is initiatedat the device 18. FIG. 7 also schematically illustrates a message deleteoperation initiated at a device 18. It should be understood that thesteps described are not necessarily presented in any particular orderand that performance of some or all of the steps in an alternativeorder(s) is possible and is contemplated. The steps have been presentedin the demonstrated order for ease of description and illustration.Steps can be added, omitted and/or performed simultaneously withoutdeparting from the scope of the appended claims. Some or all steps ofthis process, and/or substantially equivalent steps, can be performed byexecution of computer-readable instructions included on a computerreadable medium.

In an attempt to simplify the description of the method 400, variousnetwork elements and nodes have been omitted from the illustrated callflow diagram. Similarly, messages and data are described in genericterms, though it will be appreciated that multiple message and dataformats, as well as multiple message and data nodes, relays, andmessaging platforms can be involved in any or all of the communicationsdescribed herein.

As illustrated in FIG. 7, the method 400 can begin at step 402, whereinthe device 18 can receive a command to archive a designated message. Thearchive command selected by a user, for example, through selection of an“Archive” command at a GUI operated by the device 18. As illustrated atstep 404, the device 18 can archive the selected message.

The term “archive,” as used in the illustrated methods, in thedescription, and in the claims, includes various methods and systems forstoring messages and preventing deletion of the messages. In someembodiments, an “archived” message is tagged with data that indicatesthat the message is to be treated as archived by the VMS 24. Such datatagging can include the placement of an “archived” tag in the messageheader. As such, a device 18 can recognize a message as archived byrecognizing data in the message. As such, deletion of the message can berestricted or limited by the device 18 to prevent unintentionaldeletion. For example, the device 18 can require additional steps by theuser to effect deletion of the message. In other embodiments, thearchived messages can be effectively “sequestered” from the othermessages, for example, stored in an alternative folder or memory 62. Assuch, a user may have to enter the archived message folder to viewand/or delete an archived message. It will be appreciated thatadditional steps can be required before allowing deletion of an archivedmessage regardless of whether the archived messages are stored in aseparate folder, a separate memory location, and/or tagged as archived.For example, a user may be required to enter an additional password,PIN, a confirmation command, and/or other information to confirmdeletion of an archived message.

If a message is archived by a user, there may be more than one copy ofthe message on the device 18, the VMS 24, or both. In the illustratedembodiment, a user can decide to delete the message from a voicemailinterface at the device 18 at any point, as illustrated at block 406.The delete message command can be selected by a user, for example,through a GUI at the device 18. In the illustrated method 400, thedevice 18 deletes the selected message from the device memory 62, asillustrated by step 408. In the illustrated embodiment, the archivedcopy of the message is not deleted at step 408, and instead remains inthe device memory 62 until the archived copy is deleted by a user. Avoicemail application can be configured to require the user to enter anarchived message folder to select and delete an archived message, toenter a verification code, to enter a password or PIN, and the like, todelete an archived message. Requiring such operations can be useful inprotecting archived messages from unintended deletion.

As illustrated by step 410, the device 18 can also send a delete messagerequest to the VMS 24. The VMS 24 can delete the designated message, asillustrated at step 412 and explained above with reference to FIGS. 5and 6. It will be appreciated that a user can decide to delete thearchived message, at which time the message can be deleted from thedevice 18. Additionally, a user can decide to “restore” the deletedmessage from the archive, for example, by selecting an option to move orcopy the archived message to the voicemail inbox. If a user decides torestore a deleted message, the device 18 can send the message content tothe VMS 24 with instructions to place a copy of the message in thevoicemail inbox, if desired. A message that is restored to the VMS 24can appear as a new message, as a message that has already beenretrieved, or as an archived message, according to a network, VMS, oruser preference. It should be understood that some embodiments of thepresent disclosure allow message data at the VMS 24 to be decoupled frommessage data stored at the device 18, and/or vice versa. Decouplingmessage data at the VMS 24 and the device 18 can help relieve burden onthe communications network 10, for example, by reducing networkcommunications between the device 18 and the VMS 24. In someembodiments, message data is stored at a device 18, which can helprelieve burden on the VMS 24, and/or the communications network 10 ingeneral, by using the device memory 62 for storing the message data. Assuch, it should be appreciated that the device 18 may not update the VMS24 when actions are taken at the device 18, for example, deletion of amessage. The ability to decouple message data at the device 18 and theVMS 24 can be included in embodiments of other methods and systemsdescribed herein.

In FIG. 7, the archived message, as explained briefly above, can bestored indefinitely, until deletion by the user. The archival ofmessages can be continued independent of any action taken at the device18 or at the VMS 24. As noted above with reference to FIGS. 5 and 6, itis considered advantageous to allow the VMS 24 and the device 18 to synccontents at desired intervals, upon occurrence of an update, or basedupon other trigger events. Such functionality can obviate the need for auser to delete a message from a VMS 24 and a device 18 at which copiesof a voicemail message are stored. As such, as illustrated in FIGS. 5and 6, the deletion of a message at a VMS 24, for example, can trigger amessage to the device 18 to delete a corresponding copy of the messagestored at the device 18. Similar processes can be undertaken by avoicemail client at a device 18. The archive function can be used toallow permanent maintenance of the voicemail messages, irrespective ofactions of the VMS 24. Exemplary actions that can be ignored by avoicemail archival application include the deletion of a message via aTUI or GUI, the automatic deletion of old messages from a VMS 24, andthe like.

FIG. 8 schematically illustrates an exemplary method 500 for archiving amessage at a VMS 24, wherein the archival of a message is initiated atthe VMS 24. FIG. 8 also schematically illustrates a method for deletinga message at a device 18. It should be understood that the stepsdescribed are not necessarily presented in any particular order and thatperformance of some or all of the steps in an alternative order(s) ispossible and is contemplated. The steps have been presented in thedemonstrated order for ease of description and illustration. Steps canbe added, omitted and/or performed simultaneously without departing fromthe scope of the appended claims. Some or all steps of this process,and/or substantially equivalent steps, can be performed by execution ofcomputer-readable instructions included on a computer readable medium.

In an attempt to simplify the description of the method 500, variousnetwork elements and nodes have been omitted from the illustrated callflow diagram. Similarly, messages and data are described in genericterms, though it will be appreciated that multiple message and dataformats, as well as multiple message and data nodes, relays, andmessaging platforms can be involved in any or all of the communicationsdescribed herein.

As illustrated in FIG. 8, the method 500 can begin at step 502, whereatthe VMS 24 can receive a command to archive a designated message. Thearchive command selected by a user, for example, through selection of anarchive command at a TUI or other user interface run by, at, or for theVMS 24. As illustrated at step 504, the VMS 24 can archive the selectedmessage. The archived message, as described above with reference to FIG.7, can be stored indefinitely, until deletion by the user, irrespectiveof any action taken at the device 18 or at the VMS 24. In someembodiments, the storage of the archived messages can continueindefinitely unless some designated intentional deletion operation isperformed by a user, thereby denoting that the user wishes to delete thearchived message. Such options, if included, can be tailored by users,network operators, or other authorized parties. The remainder of FIG. 8illustrates a hypothetical situation in which a user decides to delete amessage after archival at the VMS 24.

As shown at step 506, a user can enter a command to delete a message atthe device 18. The delete message command can be selected by a user, forexample, through a GUI at the device 18. In the illustrated method 500,the device 18 deletes the selected message from the device memory 62, asillustrated by step 508. The device 18 can then send a “delete_message”notification to the VMS 24 to delete the message, as illustrated at step510. However, the archived copy of the message is not deleted at step512, and can remain in the VMS memory 36 until it is deleted by a user.It will be understood that archival of a message can prompt the VMS 24or the device 18 to create a copy of the message. The copy of themessage can be moved to an archive 56, tagged as archived, or placed ina special directory, location, server, or the like, if desired. In someof the embodiments in which archival of a message prompts the creationof a message copy, the receipt of a “delete_message” as illustrated instep 510 of FIG. 8 can prompt the VMS 24 to delete any copies of thearchived message out of the message inbox, for example. The archivedcopy of the message, however, can be stored until explicitly deleted, asexplained above with respect to FIG. 7.

FIG. 9 schematically illustrates a method 600 for archiving a message,according to an alternative embodiment of the present disclosure,wherein the command to archive a message is received at a device 18.FIG. 9 also illustrates the method 600, wherein the command to archive amessage is received at the VMS 24. It should be understood that thesteps described are not necessarily presented in any particular orderand that performance of some or all of the steps in an alternativeorder(s) is possible and is contemplated. The steps have been presentedin the demonstrated order for ease of description and illustration.Steps can be added, omitted and/or performed simultaneously withoutdeparting from the scope of the appended claims. Some or all steps ofthis process, and/or substantially equivalent steps, can be performed byexecution of computer-readable instructions included on a computerreadable medium.

In an attempt to simplify the description of the method 600, variousnetwork elements and nodes have been omitted from the illustrated callflow diagram. Similarly, messages and data are described in genericterms, though it will be appreciated that multiple message and dataformats, as well as multiple message and data nodes, relays, andmessaging platforms can be involved in any or all of the communicationsdescribed herein.

As illustrated in FIG. 9, the method 600 can begin at step 602, whereatthe device 18 can receive a command to archive a designated message. Thearchive command can be selected by a user, for example, throughselection of an archive command at a GUI operated by the device 18. Asillustrated at step 604, the device 18 can send a “save_message”notification to the VMS 24.

Alternatively, the method 600 can begin at step 606, wherein the VMS 24receives a command to archive a designated message. In the illustratedembodiment, the VMS 24 can receive a command to archive a designatedmessage by the selection of an option to archive a designated message ata TUI, or by receiving a “save_message” command, as illustrated anddescribed at step 604.

As illustrated at step 610, the VMS 24 saves the selected or designatedmessage. The message save operation illustrated at step 610 can beperformed in a manner substantially similar to a save operationperformed by many traditional voicemail systems, visual voicemailsystems, and the like. In the illustrated embodiment of FIG. 9, saving amessage at the VMS 24 can also prompt the VMS 24 to set and initiate atimer for the message, the expiration of which will prompt the VMS 24 todelete the message from the VMS memory 36. If the archive command isselected at the device 18, as shown at step 602, the device 18 canautomatically send a “save_message” command at a specified interval, asillustrated at step 612. Upon receipt of the “save_message” command, theVMS 24 can save the designated message again, thereby re-starting thetime for which the message will be stored, as illustrated at step 614.It will be appreciated that the save and re-save functionality can beperformed by the VMS 24, without input from the device 18, in which casethe VMS 24 will re-save the message at a designated interval to preventremoval of a designated message from the VMS 24. For example, thearchive command can be entered at the VMS 24, for example, by a useraccessing the VMS 24 through a TUI or other user interface. The VMS 24can include functionality that re-saves the selected message at somedesignated interval to prevent removal of the message from the VMS 24.In another embodiment, the archive command is selected at a device 18and the archive command is passed to the VMS 24. The VMS 24 thenimplements a process to re-save the message at a designated interval toprevent deletion of the designated message. In still other embodiments,an archival module (not illustrated) can be used to archive messages atthe VMS 24. An archival module can reside on the network 10, the device18, or a combination thereof, and can be hardware, software, and/or acombination thereof. The selection of the archival command at the VMS 24or at the device 18 can pass instructions to the archival module. Theinstructions can command the archival module to archive one or moredesignated messages. The archive module can then connect to the VMS 24or the device 18, authenticate as the user or the device 18, and savethe designated message at designated intervals.

FIG. 10 illustrates an exemplary representative image from a GUI 700 fora device 18, according to an exemplary embodiment of the disclosure. Asillustrated, the GUI 700 can include operational information 702 for thedevice 18. The operational information 702 can include networkinformation, for example, a signal meter 704 for displaying the measuredstrength of a network signal, and a network indicator 706 for displayingthe current network to which the device 18 is connected. In theillustrated GUI 700, the device 18 is indicating a maximum signalstrength and that the device 18 is currently connected to the AT&T EDGE(Enhanced Data rates for GSM Evolution) network. It should be understoodthat this indication is exemplary only since the GUI 700 can be used ondevices operating on other networks and operated by other carriers. Theoperational information 702 can also include, for example, the time ofday 708, a battery meter 710, as well as other indicators, including,but not limited to, a short range radio communications device indicator,an alarm indicator, a date, and the like.

In the illustrated GUI 700, an exemplary visual voicemail applicationuser interface (VVMAUI) 712 is currently displayed. The reader isreminded that the methods and systems described herein are not limitedto visual voicemail systems. Rather, the VVMAUI 712 is illustrated tosimplify description of the concepts disclosed herein. The illustratedVVMAUI 712 includes a title and/or menu portion 714, a mailbox contentsportion 716, and a control portion 718. As illustrated, the title and/ormenu portion 714 can include one or more options 720, if desired, thoughthe illustrated options are merely exemplary. The mailbox contentsportion 716 can display one or more messages 722, an option 724 to viewdeleted messages, an option 726 to view archived messages, as well asother options (not illustrated). The control portion 718 can include oneor more controls, if desired. The illustrated control portion 718includes a callback option 728, a time slider bar 730, a delete option732, and an option 734 to archive a message 722. In the illustrated GUI700, the control portion 718 is illustrated as being in a deactivatedstate. In the exemplary illustrated GUI 700, the control portion 718 canbe activated when a desired message is selected for review by the user.

In some embodiments, the GUI 700 is controlled by using buttons,soft-buttons, joysticks, switches, wheels, or the like on a devicekeypad. In other embodiments, the voicemail client is run using aninput/output device operatively connected to the device 18. In otherembodiments, the GUI 700 also functions as a touch-sensitive inputdevice for accepting user input, whereby a user can touch the screen ata desired option to enter a command corresponding to the selectedoption. In still other embodiments, a combination of input devices areused to make desired selections. These and other embodiments areincluded in the scope of the appended claims.

Selection of the illustrated “Archive” option 734 can instruct thedevice to archive the selected message. Archival of messages can beaccomplished in a number of ways, as explained above. For example,selection of the “Archive” option 734 can instruct the device to send amessage to the VMS 24 requesting archival of the selected message, aswas explained above with reference to FIG. 7. In other embodiments, allvoicemail messages are stored locally, in a device memory 62. A messagedesignated for archival can be tagged with header data that indicates tothe device 18 that the message is to be stored until deleted by theuser. Additionally, or in the alternative, an archived message can bestored in a special memory location to prevent inadvertent deletionwithout the addition of additional header data. In other embodiments,archival of a message can result in a “save” command being sent to theVMS 24 to save a message, whereby a timer can be initiated, theexpiration of which allows the VMS 24 to delete the message. The VMS 24or the device 18 can resend the “Save” command at intervals that willprevent expiration of the timer, thereby preventing deletion of themessage. Other embodiments are contemplated and are included in thescope of the appended claims. Regardless of the method used to archivemessages, the device 18 knows which messages are archived and allows auser to review the archived messages as desired.

FIG. 11 illustrates another exemplary representative image from a GUI700 for a device 18, according to an exemplary embodiment of thedisclosure. In FIG. 11, the user has entered the archived messages box,in which two messages 736 are represented as being archived. Asexplained above, the messages 736 can be stored on a network element andthe device 18 can provide the user with an indication that the messagesare archived. It should be understood that the two messages 736 may havebeen selected for archival by the user, may have been automaticallyarchived by the device 18, automatically archived by the VMS 24, orotherwise noted as being archived. If the user selected to archive themessages 736 at the device 18, the user may have used an archive optionthat is substantially similar to the illustrated archive option 734 ofFIG. 10. The messages 736 depicted in FIG. 11 may be stored in a devicememory 62, on a network element, in the VMS memory 36, in the archive 56of the VMS, or in an alternative memory location at the device 18, theVMS 24, the communications network 10, at a combination of locations,and the like.

FIG. 12 illustrates another exemplary representative image from a GUI700 for a device 18, according to an exemplary embodiment of thedisclosure. In the illustrated GUI 700, the user has selected a message740, which is illustrated as highlighted. Since the user has selected amessage 740 for review, the control portion 718 is illustrated as beingin an activated state. The time slider bar 730 shows the length of theselected message 740. As illustrated, the selected message 740 iscurrently at the 0:00 position and 2 minutes and 07 seconds (2:07)remain in the selected message 740. In the illustrated GUI 700, anoption 742 to play the selected message 740 appears to the left of theselected message 740. It is noted that the appearance of the unselectedmessage 736 can be substantially similar to the appearance of anunselected message 736 illustrated in FIG. 11.

In FIG. 12, the GUI 700 includes other exemplary controls, for example,a callback option 728, a delete option 732, and a forward option 734.The callback option 728 allows a user to place a phone call to thenumber from which the message was left. The delete option 732 allows themessage to be deleted from the archive. It will be appreciated thatselection of a delete option from the archive can prompt the device 18to obtain additional instructions from the user. For example, the device18 may prompt the user to instruct the device 18 whether to delete themessage permanently, to move the message back to the inbox, or the like.The illustrated forward option 734 can be used to forward the selectedmessage. The message can be converted to alternative formats orforwarded without conversion. A basic conversion and forward method isdescribed in more detail below with reference to FIG. 15.

FIG. 13 illustrates another exemplary representative image from a GUI700 for a device 18, according to an exemplary embodiment of thedisclosure. In FIG. 13, the user has selected the forward option 734illustrated in FIG. 12 to forward the selected message 740. In thisembodiment, selection by the user of the forward option 734 prompts theuser to select a desired delivery method for the forwarded message. Theillustrated GUI 700 includes options to convert the message to one ormore of several possible formats, and to select a delivery method. Itshould be understood that the illustrated conversion formats anddelivery methods are exemplary only. Furthermore, it will be understoodthat the conversion and forwarding options are both optional, and thatone, both, or neither of the options can be included as options forselection by a user.

In the illustrated GUI 700, the selected message 740 is displayed at thetop of the image, and a number of options are presented to the user forselection. The illustrated GUI 700 includes an option 744 to convert theselected message audio to text. The speech to text option 744 can beused to convert a spoken message to readable text. The readable text canbe stored as a text file at the device or at a network element andforwarded as an attachment to an email or MMS message. Alternatively,the text file can be stored at a network element for retrieval by athird party or third party device.

The illustrated GUI 700 also includes an option 746 to convert an audiomessage from speech to text message(s). Selection of the speech to textmessage option 746 can prompt the device 18 to convert a spoken messageto text and forward the readable text to a designated recipient as oneor more text messages. The text messages can be sent using, for example,short message service (SMS) protocol. Other options are contemplated andpossible.

The illustrated GUI 700 also includes an option 748 to send the message740 as an MMS attachment. Selection of the MMS attachment option 748 cancreate a new MMS message with an audio, video, or text file attachment.The user can enter one or more recipients of the MMS message. Asillustrated, the MMS attachment option 748 can include an option 750 toenter a submenu through which additional options can be presented to theuser. In one embodiment, the submenu prompts the user to select adesired conversion format for the message attachment. In anotherembodiment, the submenu prompts the user to designate one or morerecipients and the device 18, or a network element, determines theproper delivery format of the MMS attachment. In still anotherembodiment, the submenu includes a combination of these and otheroptions.

The illustrated GUI 700 also includes an option 752 to send the message740 as an email attachment. Selection of the email attachment option 752can create a new email message with an audio, video, or text fileattachment. The user can enter one or more recipients of the emailmessage, as is known. As illustrated, the email attachment option 752can include an option 754 to enter a submenu through which additionaloptions can be presented to the user. In one embodiment, the submenuprompts the user to select a desired conversion format for the messageattachment. In another embodiment, the submenu prompts the user todesignate one or more recipients and the device 18, or a networkelement, determines the proper delivery format of the email attachment.In still another embodiment, the submenu includes a combination of theseand other options.

The illustrated GUI 700 also includes an option 756 to attach aforwarding message to the forwarded message 740. A forwarding messagecan include a standard or custom greeting that can be sent with theforwarded message 740. In some embodiments, the user records ordesignates a custom greeting introducing the user to the one or morerecipients of the forwarded message 740. In some embodiments, theforwarding message is joined to the forwarded message 740 to create asingle audio, video, or text file. In other embodiments, the forwardingmessage and the forwarded message 740 are sent as separate files in oneor more file formats. The forwarding message can be a standard message,a recording tailored to the forwarded message 740, a default message,and the like. It will be appreciated that if the user sends theforwarded message 740 as an email or MMS attachment, that the user canuse the body of the email or MMS message as the forwarding message.However, if desired, the user can attach a forwarding message insteadof, or in addition to, the body of the email or MMS message, forexample. As illustrated, the attach forwarding message option 756 caninclude an option 758 to enter a submenu through which additionaloptions can be presented to a user. For example, a submenu can allow theuser to select a prerecorded forwarding message, to record a custommessage for a forwarded message 740, to select or enter a text message,to select an option to join the forwarding message and the forwardedmessage as a single file, other options, combinations thereof, and thelike.

The illustrated GUI 700 also includes an option 760 to allow a thirdparty to retrieve the “forwarded” message 740. The third party retrievaloption 760 allows a user to authorize retrieval by one or more thirdparties. The message can be stored at the device 18, at the VMS 24, orat another element on a communications network 10. The third partyretrieval option 760 can include an option 762 to enter a submenuthrough which additional options can be presented to a user. Forexample, a submenu can allow the user to designate one or more thirdparties who are authorized to retrieve the message 740. Additionally,the submenu can allow a user to designate a medium through which theforwarded message 740 can be retrieved. In some embodiments, the thirdparty retrieval option 760 will move the forwarded message 740 to alocation and send a link to the third party. The third party canretrieve the forwarded message 740 from the location designated by theforwarded link. In other embodiments, the third party retrieval option760 sends retrieval information to the one ore more third parties. Theretrieval information can include a telephone number and an access code,through which the one ore more third parties can connect to the VMS 24and retrieve the forwarded message 740. Other options and combinationsof options can be included in the submenu, if desired.

The illustrated GUI 700 also includes a cancel option 764, through whichthe user can cancel the conversion and/or the forwarding process. Thecancel option 764 can be a selectable option, or can correspond to asoft key on a device keypad, for example. The GUI 700 can also include aconvert option 766. In some embodiments, selection of any or all of theexemplary illustrated options 744-762 can prompt the device 18 to beginperforming the selected operation. In other embodiments, the user canselect a desired option 744-762 and then select the convert option 766,after which the device can begin converting the forwarded message 740 inaccordance with the selected option 744-762.

FIG. 14 illustrates another exemplary representative image from a GUI700 for a device 18, according to an exemplary embodiment of thedisclosure. The illustrated GUI 700 is an exemplary embodiment of anemail program for forwarding a forwarded message 740 as an emailattachment. FIG. 14 is merely illustrative of an exemplary GUI 700 thatcould result from the selection of the email attachment option 752 ofFIG. 13, for example. The illustrated GUI 700 includes one or moreaddress fields 768, a subject line 770, an attachment line 772, and amessage body portion 774. It will be appreciated some or all of theaddress fields 768, the subject line 770, the attachment line 772, andthe message body portion 774 can be automatically populated by thedevice 18, or an application running thereon.

The GUI 700 is illustrated as including a cancel option 776, theselection of which can cancel the forwarding of the forwarded message740. The illustrated GUI 700 also includes a send option 780, theselection of which prompts the device 18 to attempt delivery of theforwarded message 740. It will be appreciated that additional oralternative options are possible and contemplated. As was explainedabove, the cancel option 776 and the send option 780 can be selectableusing a touch-sensitive screen, a joystick, softkeys, and the like.While the illustrated embodiment illustrates the forwarded message asattached to the outgoing email message as a file, it will be appreciatedthat the forwarded message 740 can be converted to text and attached toor can be an SMS message, an MMS message, an email message, a text file,and the like.

FIG. 15 schematically illustrates an exemplary method 800 for optionallyconverting and forwarding a voicemail message according to severalexemplary embodiments of the disclosure. It should be understood thatFIG. 15 illustrates in general terms an exemplary method for optionallyconverting and forwarding voicemail messages as conversion andforwarding functions can be included in a VMS 24 made in accordance withexemplary embodiments of the present disclosure. The steps of the method800 are not necessarily presented in any particular order and thatperformance of some or all the steps in an alternative order(s) ispossible and is contemplated. The steps have been presented in thedemonstrated order for ease of description and illustration. Steps canbe added, omitted and/or performed simultaneously without departing fromthe scope of the appended claims. It should also be understood that theillustrated method 800 can be ended at any time. Some or all steps ofthis process, and/or substantially equivalent steps, can be performed byexecution of computer-readable instructions included on a computerreadable medium.

As illustrated in block 802, a VMS 24 can store one or more messages. Asexplained above with reference to FIG. 2, the message 52 can includevarious types of data, including, but not limited to, audio data, videodata, headers, text, and the like, and that the VMS 24 can correlate thevarious data, if desired, to represent a message. It will be appreciatedthat the message storage referred to with reference to block 802 canoccur any number of times, or not at all, before a user of the VMS 24retrieves any messages. Additionally, it will be appreciated thatvoicemail setup and configuration of mailbox preferences, and the like,are not illustrated for the sake of brevity, though such steps can occurat any time.

As illustrated in block 804, a user or the device 18 can connect to theVMS 24. A user or the device 18 can connect to the VMS 24 by a voiceconnection, by a data connection, or over the internet, for example.Once the user or the device 18 connects to the VMS 24, the VMS 24 canauthenticate a user or the device 18 to determine if the user or thedevice 18 is authorized to access the requested mailbox, as illustratedin block 806. Although not illustrated, a user or the device 18 may begiven several attempts to authenticate to the VMS 24, or the VMS 24 canterminate a call after an unsuccessful authentication attempt. For theremainder of the illustrated method 800, it will be assumed that theuser or the device 18 authenticates successfully to the VMS 24.

As illustrated in block 808, the VMS 24 can retrieve one or moremessages for the user or the device 18. In some embodiments, the user'sdevice 18 connects to the VMS 24 and retrieves only the message headers.If a user selects a particular message, the message content, forexample, the audio, video, text, or other data, can be retrieved by theuser's device 18, as explained above with reference to FIG. 2. In someother embodiments, the user's device 18 can retrieve all of the data forall of the messages received at the VMS 24. In still other embodiments,the data for messages remains on the VMS 24 during a message retrievalby a user or the device 18. In still other embodiments, the VMS 24includes hardware, software, or a combination thereof, at the device 18.At any time, any of the messages can be archived, as explained above indetail.

At block 810, the VMS 24 can receive instructions to forward one or morearchived messages, or portion(s) thereof. The instructions to forward amessage can be received in a number of ways. For example, a voicecommand, a DTMF tone, a data message, or the like, corresponding to adesired action, can be passed to and executed by the VMS 24 or thedevice 18. It should also be appreciated that a device 18 can include aGUI for presenting options to a user and for receiving the user's optionselection. When a user makes a selection, the device 18 can implementthe selected option or pass data corresponding to the selected option tothe VMS 24 for execution. In the illustrated method 800, the user hasindicated that one or more messages are to be forwarded to a recipient.The instructions to forward the message can optionally include contactinformation for a designated recipient, or the exemplary method 800 canoptionally include prompting a user or the device 18 to select ordesignate a recipient. Alternatively, the VMS 24 can optionally beconfigured to forward messages to a default address, for example, theuser's email address, or the user's device 18.

At block 812, the VMS 24 can optionally convert one or more messages, orportion(s) thereof, into a desired or designated format, as wasexplained above with reference to FIG. 13, for example. The desired ordesignated format can be set by a user, by the device 18, by the VMS 24,by the designated recipient, or by any other authorized party. In oneembodiment, the VMS 24 sets the default message conversion format. Inanother embodiment, the user designates the message conversion formatand stores the choice in the preferences. In another embodiment, theuser can set the conversion format each time a message is forwarded, asillustrated above in FIG. 13. In another embodiment, the VMS 24identifies the conversion format by retrieving information relating tothe recipient device, for example, the recipient telephone number, therecipient device IMEI, the recipient's network, the recipient's IPaddress, the recipient's location, and the like. As such, it should beappreciated that a determination step can be included in the illustratedmethod 800 in which the user, the VMS 24, or another element, designatesor determines the conversion format for the message, or portion thereof.Alternatively, as explained above, the message, or a portion thereof,can be forwarded without being converted into an alternative fileformat.

At block 814, the VMS 24 or the device 18 can forward the message, aportion thereof, or instructions for retrieving the message, to arecipient. As briefly described above, the message recipient can bedesignated by the user, by the VMS 24, selected by the user, and thelike. The illustrated method 800 can include verification steps toensure that the message is received by the recipient device, connectionand communication steps between the VMS 24, the device 18, and therecipient device, depending upon the selected forwarding method and/orformat. The method 800 can end.

While the preceding description has described voicemail messagesprimarily in the context of audio and text messages, it should beappreciated that the VMS 24 can also process, store, archive, convert,and/or forward (handle) video messages, if desired. In the event thatthe VMS 24 is configured to handle video messages, many of the sameprocesses described above with respect to video and text messages can beused to handle the messages. For example, a video file can include avideo component and an audio component. As such, the VMS 24 can archive,convert, and/or forward the audio file, the video file, or both. Theconversion can include a speech to text converter, CODECs, and the like,as explained above. As such, a user can archive, convert, store,forward, receive, and retrieve messages as video, audio, text,combinations thereof, and the like.

It must be understood that the illustrated GUIs are exemplary only andother contemplated user interfaces, screen layouts, selection methods,and the like are contemplated, including an embodiment of the VMS 24that does not provide a GUI at the user's device, the calling party'sdevice, or either device. Furthermore, a selection can be made usingvarious embodiments of softkeys and/or key selections on a mobile orstationary telephone keypad, for example, and is not limited to theillustrated GUI. Additional and/or alternative selector switches andjoysticks can be used to select a desired option or icon correspondingto a desired option. Input methods can also include touch screens orvoice commands. Any desired screen layout or format can be used,including plain text and icons, for example.

The law does not require and it is economically prohibitive toillustrate and teach every possible embodiment of the present claims.Hence, the above-described embodiments are merely exemplaryillustrations of implementations set forth for a clear understanding ofthe principles of the disclosure. Variations, modifications, andcombinations may be made to the above-described embodiments withoutdeparting from the scope of the claims. All such variations,modifications, and combinations are included herein by the scope of thisdisclosure and the following claims.

We claim:
 1. A device comprising: a processor; and a memory that storesinstructions that, when executed by the processor, cause the processorto perform operations comprising receiving a message associated with amobile device, storing a copy of the message in the memory, receiving acommand to forward the message to a recipient device, retrieving thecopy of the message from the memory, and forwarding the copy of themessage to the recipient device.
 2. The device of claim 1, wherein theinstructions, when executed by the processor, cause the processor toperform operations further comprising: retrieving information relatingto the recipient device; and determining, based upon the information, aconversion format for the copy of the message.
 3. The device of claim 2,wherein the instructions, when executed by the processor, cause theprocessor to perform operations further comprising: converting the copyof the message from a format to the conversion format; and forwardingthe copy of the message converted to the conversion format to therecipient device.
 4. The device of claim 1, wherein the instructions,when executed by the processor, cause the processor to performoperations further comprising: attaching a forwarding message to thecopy of the message.
 5. The device of claim 1, wherein the instructions,when executed by the processor, cause the processor to performoperations further comprising: receiving a further command to archivethe copy of the message.
 6. The device of claim 1, wherein receiving thecommand to forward the message comprises receiving, from the mobiledevice, the command.
 7. The device of claim 1, wherein receiving thecommand to forward the message comprises receiving, via a userinterface, selection of an option to forward the message.
 8. The deviceof claim 1, wherein forwarding the copy of the message to the recipientdevice comprises: sending retrieval instructions to the recipientdevice; detecting a request, from the recipient device, for the copy ofthe message; and providing, to the recipient device, the copy of themessage in response to the request.
 9. A method comprising: receiving,at a device comprising a processor, a message associated with a mobiledevice; storing, by the device, a copy of the message at a memory;receiving, by the device, a command to forward the copy of the messageto a recipient device; retrieving, by the device, the copy of themessage from the memory, and forwarding, by the device, the copy of themessage to the recipient device.
 10. The method of claim 9, furthercomprising: retrieving information relating to the recipient device; anddetermining, based upon the information, a conversion format for thecopy of the message.
 11. The method of claim 10, further comprising:converting the copy of the message from a format to the conversionformat; and forwarding, to the recipient device, the copy of the messageconverted to the conversion format.
 12. The method of claim 9, furthercomprising: attaching a forwarding message to the copy of the message.13. The method of claim 9, further comprising: receiving a furthercommand to archive the copy of the message.
 14. The method of claim 9,wherein forwarding the copy of the message to the recipient devicecomprises: sending retrieval instructions to the recipient device;detecting a request, from the recipient device, for the copy of themessage; and providing, to the recipient device, the copy of the messagein response to the request.
 15. A non-transitory computer-readablestorage medium that stores instructions that, when executed by aprocessor, cause the processor to perform operations comprising:receiving a message associated with a mobile device; storing a copy ofthe message at a memory; receiving a command to forward the copy of themessage to a recipient device; retrieving the copy of the message fromthe memory, and forwarding the copy of the message to the recipientdevice.
 16. The non-transitory computer-readable storage medium of claim15, wherein the instructions, when executed by the processor, cause theprocessor to perform operations further comprising: retrievinginformation relating to the recipient device; and determining, basedupon the information, a conversion format for the copy of the message.17. The non-transitory computer-readable storage medium of claim 16,wherein the instructions, when executed by the processor, cause theprocessor to perform operations further comprising: converting the copyof the message from a format to the conversion format; and forwarding,to the recipient device, the copy of the message converted to theconversion format.
 18. The non-transitory computer-readable storagemedium of claim 15, wherein the instructions, when executed by theprocessor, cause the processor to perform operations further comprising:attaching a forwarding message to the copy of the message.
 19. Thenon-transitory computer-readable storage medium of claim 15, wherein theinstructions, when executed by the processor, cause the processor toperform operations further comprising: receiving a further command toarchive the copy of the message.
 20. The non-transitorycomputer-readable storage medium of claim 15, wherein forwarding thecopy of the message to the recipient device comprises: sending retrievalinstructions to the recipient device; detecting a request, from therecipient device, for the copy of the message; and providing, to therecipient device, the copy of the message in response to the request.